Go sale dos veces al año: una versión en febrero y otra en agosto. Go 1.26 es la de febrero de 2026, justo seis meses después de Go 1.25. Si vienes de Go 1.24, que es la versión que más proyectos en producción siguen usando, los cambios acumulados son bastante notables.
Lo primero que conviene recordar: Go garantiza compatibilidad hacia atrás. Código escrito para Go 1.0 compila sin modificaciones con Go 1.26. No hay breaking changes. Actualizar el toolchain es seguro.
La directiva tool en go.mod (desde Go 1.24)
Uno de los cambios más prácticos llegó con Go 1.24 y merece explicarse bien porque cambia cómo se gestionan las herramientas de desarrollo.
Antes, si querías usar golangci-lint, stringer o mockery en tu proyecto, tenías dos opciones malas: instalarlo globalmente en tu máquina (con la versión que tocara) o mantener un script con go install que nadie actualizaba. Ahora puedes declarar las herramientas directamente en go.mod:
tool golang.org/x/tools/cmd/stringerY ejecutarlas así:
go tool stringer -type=Color .El toolchain descarga la versión exacta que especifica el módulo y la ejecuta. go mod tidy la incluye en go.sum. Es el equivalente a devDependencies de npm pero para herramientas de generación de código, y resuelve un problema real que los equipos grandes llevaban años parcheando con Makefiles.
Green Tea GC: el nuevo recolector de basura pasa a ser el predeterminado
Este es el cambio más grande de Go 1.26 y el que más va a notarse en producción.
El GC de Go llevaba años siendo el mismo: tricolor mark-and-sweep concurrente. Funciona bien, pero en servicios con mucho heap y muchas goroutinas activas generaba pausas de entre 0,1 y 1 milisegundo que en workloads de alta frecuencia se acumulaban y subían los percentiles p95 y p99.
Green Tea es el nuevo recolector, experimental desde Go 1.25 y predeterminado en Go 1.26. Su objetivo es reducir la latencia de pausa y mejorar el throughput en esos escenarios mixtos. En Go 1.25 podías probarlo activándolo a mano:
GOEXPERIMENT=greenteagc go build .En Go 1.26 no hace falta nada. Está activo por defecto. Benchmarks publicados por equipos con servicios REST de alta carga muestran reducciones del 15 al 30% en p99 latency sin tocar una línea de código.
Si por algún motivo necesitas el comportamiento anterior mientras migras, puedes desactivarlo temporalmente con una variable de entorno, pero en la mayoría de casos no hará falta.
CGo: 30% menos de overhead en llamadas cruzadas
CGo permite llamar a código C desde Go. El precio clásico era una barrera costosa en cada llamada: Go y C usan stacks distintos y el runtime tenía que hacer un stack switch cada vez que cruzabas la frontera.
Go 1.26 reduce ese coste en torno a un 30% gracias a una mejor gestión de esos switches. Para proyectos que usan CGo de verdad, como los que integran SQLite nativo, OpenSSL o cualquier librería C mediante FFI, la mejora llega sin tocar el código. Solo actualizar el toolchain.
Si tu proyecto no usa CGo, este cambio no te afecta directamente, pero es una señal de que el equipo de Go está invirtiendo en hacer viables más tipos de integraciones.
Mejoras en go test: output JSON más rico
El flag --json de go test ya existía, pero el output era bastante básico. En Go 1.26 añade timestamps más precisos por cada test individual, lo que facilita detectar qué tests son lentos sin necesidad de herramientas externas.
Dos flags que vale la pena combinar si no los usas ya:
go test -count=1 -shuffle=on ./...-shuffle=on aleatoriza el orden de los tests en cada ejecución. Si tus tests pasan en orden fijo pero fallan aleatoriamente, hay dependencias de estado entre ellos. Este flag las saca a la superficie sin esfuerzo.
El fuzzing también mejora: el scheduler del fuzz runner es más eficiente a la hora de explorar el espacio de inputs, lo que significa que encuentra bugs más rápido con la misma cantidad de tiempo de CPU.
WASM y WASI: Go en funciones serverless
Desde Go 1.21 existe soporte para WASI (WebAssembly System Interface), la interfaz que permite ejecutar módulos WebAssembly fuera del navegador, por ejemplo en runtimes serverless como Spin de Fermyon o WasmEdge.
Compilar un binario WASI es directo:
GOOS=wasip1 GOARCH=wasm go build -o main.wasm .Go 1.26 amplía el soporte con mejor manejo de sockets y operaciones de filesystem desde WASI. Esto abre la puerta a escribir funciones serverless en Go que se ejecuten en cualquier runtime compatible con WASI sin depender de un proveedor concreto.
El único punto débil sigue siendo el tamaño del binario: los ejecutables WASM de Go pesan varios megabytes porque incluyen el runtime completo. Para serverless de larga duración no es problema, pero para funciones muy pequeñas puede ser un inconveniente frente a lenguajes más compactos.
Mejoras heredadas de versiones anteriores que ya son estándar
Algunas características que llegaron en Go 1.22 y 1.23 están ya tan integradas que conviene recordarlas si actualizas desde versiones antiguas.
range sobre enteros
Desde Go 1.22 puedes iterar sobre un entero directamente:
for i := range 10 {
fmt.Println(i) // 0, 1, 2, ..., 9
}Elimina el clásico for i := 0; i < 10; i++ en los casos simples.
slices.Collect e iteradores
Desde Go 1.23, la stdlib incluye soporte para iteradores genéricos. slices.Collect(iter) convierte cualquier iterador a slice de forma directa, sin bucles manuales:
import "slices"
nums := slices.Collect(maps.Keys(myMap))math/rand/v2
El paquete math/rand/v2, llegado en Go 1.22, resuelve los sesgos del generador original. rand.N(n) genera enteros aleatorios uniformes sin el módulo manual que introducía sesgo:
n := rand.N(100) // entero aleatorio entre 0 y 99, sin sesgosCómo actualizar tu proyecto a Go 1.26
El proceso es sencillo. Primero, actualiza el toolchain en tu máquina o CI:
go install golang.org/dl/go1.26@latest
go1.26 downloadLuego, actualiza la versión mínima del módulo:
go get [email protected]
go mod tidyPuedes verificar qué versión está activa en cualquier momento:
go env GOVERSIONLa directiva go.toolchain en go.mod especifica el toolchain mínimo recomendado para el módulo, separada de la versión de Go mínima requerida. Útil cuando tu equipo tiene máquinas con versiones distintas.
No esperes sorpresas desagradables al actualizar. La promesa de compatibilidad de Go es una de las más sólidas del ecosistema de lenguajes modernos y se ha cumplido sin excepciones desde la versión 1.0.
¿Vale la pena actualizar ya?
Para proyectos con servicios de baja latencia o que usen CGo, sí. El Green Tea GC y la reducción de overhead en CGo son mejoras inmediatas sin coste de migración. Para el resto, la actualización sigue siendo recomendable por las mejoras en testing y la directiva tool, aunque no hay urgencia.
Si quieres ver el contexto más amplio de hacia dónde va el lenguaje, te puede interesar el estado de Go en 2025 o el análisis de Go comparado con Rust en 2026 para saber cuándo elegir uno u otro.
Imagen: Pexels / Brett Sayles